As various forms of distributed computing, such as cloud computing, have come to dominate the computing landscape, security has become a bottleneck issue that currently prevents the complete migration of various capabilities associated with sensitive data into cloud-based infrastructures, and/or other distributive computing models. This is at least partially because many owners and operators of data centers that provide access to data and other resources are hesitant to allow their data and resources to be accessed, processed, and/or otherwise used, by virtual assets in the cloud.
A major security issue in a cloud computing environment is that vulnerabilities associated with virtual assets are not always known or understood at the time the virtual assets are created and deployed, e.g., instantiated, in a given computing environment and, once deployed, detecting and/or responding to newly identified vulnerabilities through “normal” communications channels associated with the virtual assets can be challenging, if not impossible.
Current approaches to vulnerability management that typically involve addressing vulnerabilities on an ad-hoc basis as they arise, or in a simplistic, uncoordinated, static, and largely manual, manner are no longer acceptable. Indeed, in order for applications and systems that process sensitive data to fully migrate to a cloud-based infrastructure, security issues and vulnerabilities must be addressed in a proactive, anticipatory, and comprehensive manner, where the security and invulnerability to attack of virtual assets is verified well before any potential attack can possibly occur, e.g. before deployment and publishing in a production environment.
However, currently, this type of comprehensive approach to vulnerability management and verification is largely unavailable. In addition, in the few cases where a comprehensive approach to vulnerability management and verification is attempted, the vulnerabilities are typically analyzed after deployment of the virtual assets and then each virtual asset is individually verified in the production environment. Consequently, currently, vulnerability management and verification is prohibitively expensive and resource intensive, often requiring significant amounts of dedicated hardware, software, and human administrators that are still often utilized in an ad-hoc manner.
In addition, currently, virtual asset vulnerability analysis and verification management is typically done after the virtual assets are deployed in the computing environment in which they are intended to be used, i.e., in the production computing environment. However, when the virtual assets are deployed in a production computing environment it is often the case that one or more connectivity restrictions are imposed on the virtual assets in the production computing environment. That is to say, when virtual assets are deployed in a production computing environment, they are often deployed in Virtual Private Clouds (VPCs), in designated subnets, under the control of network access control lists, in various security groups, and/or in any other connectivity controlled environment created by the imposition of one or more connectivity restrictions, as discussed herein, and/or as known in the art at the time of filing, and/or as developed after the time of filing.
Given that one or more connectivity restrictions are imposed on the virtual assets in the production computing environment, when a virtual asset is subjected to vulnerability analysis and verified in the production computing environment, there is no way for the verification system to check for vulnerabilities that may be present in a situation where one or more of the connectivity restrictions have been removed. In short, if a given virtual asset is restricted to a specific type of connectivity in a production computing environment, then any vulnerability analysis and verification process can only be performed on the specific type of connectivity provided to the virtual asset in the production computing environment. As a result, no vulnerability testing or verification can be performed on the virtual asset in the production computing environment that is associated with a different, or new, type of connectivity, or operational scenario, other than the specific type of connectivity allowed for the virtual asset in the production computing environment.
In light of the situation described above, currently, the vulnerability analysis and verification process, at best, is incomplete and only provides reasonably accurate data if the virtual assets are deployed in the production computing environment exactly as intended and no changes are made to the type of connectivity, and operational parameters, expected to be provided to the virtual assets. Consequently, serious vulnerabilities may still be present in the virtual assets that will only be revealed if there is a change in the type of connectivity and/or operational scenario associated with the virtual asset. However, if there is a change in the type of connectivity and/or operational scenario associated with the virtual asset, an unexpected vulnerability may well result and, as noted above, if this vulnerability is exploited the damage done may well be irreparable and devastating.
What is needed is a method and system for providing vulnerability analysis and verification management that extends beyond the expected connectivity restrictions and production computing environment associated with a given virtual asset and allows the virtual asset to be verified to be free of vulnerabilities in a broad range of connectivity and operational environments beyond that expected and that can be tested for in the production computing environment.
In addition, in some cases, malicious entities can take control of a virtual asset. In these cases, the malicious entity often takes over, or closes down, normal communications channels associated with the virtual asset. Consequently, in some cases, the malicious entity can mask the fact they have taken control of the virtual asset from other entities outside the virtual asset, such as entities deployed by the owner to monitor and enforce security policies. This leaves the malicious entity relatively free to manipulate the virtual asset under its control and access any data used by the virtual asset, with little concern of detection by the legitimate owner of the virtual asset. Even in cases where the legitimate owner of the virtual asset does become aware that the virtual asset has been compromised, if the malicious entity has shut down, or taken control of, the normal communications channels associated with the virtual asset, the malicious entity can thwart any traditional efforts by the legitimate owner to communicate with the virtual asset and/or repair the virtual asset.
What is needed is a method and system for protecting and repairing a virtual asset from damage by potential security threats.